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Status of this Memo 
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not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 
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Abstract 


This document presents a list of requirements in support of Emergency 
Telecommunications Service (ETS) within the context of IP telephony. 
It is an extension to the general requirements presented in RFC 3689. 
Solutions to these requirements are not presented in this document. 


1. Introduction 


Effective telecommunications capabilities can be imperative to 
facilitate immediate recovery operations for serious disaster events, 
such as, hurricanes, floods, earthquakes, and terrorist attacks. 
Disasters can happen unexpectedly, at any time or place. Quick 
response for recovery operations requires immediate access to any 
public telecommunications capabilities at hand. These capabilities 
include: conventional telephone, cellular phones, and Internet 
access via online terminals, IP telephones, and wireless Personal 
Digital Assistants (PDAs). The commercial telecommunications 
infrastructure is rapidly evolving to Internet-based technology. 
Therefore, the Internet community needs to consider how it can best 
support emergency management and recovery operations. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [1]. 
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tels Problem 


Standards have been developed by other standards bodies concerning 
emergency communications. As discussed in [3], some of these 
standards, such as T1.631 [5], define specific indicators or labels 
for emergency communications in Signaling System 7 (SS7) networks. 
Certain requirements must be defined in order to achieve peering 
across hybrid networks (networks that communicate between IP and 
other types of networks, such as that realized by the Public Switched 
Telephone Network) in order to achieve an interworking of services. 


2. Scope 


[3] has defined a set of general system requirements to support 
Emergency Telecommunications Service (ETS). This document defines an 
additional set of system requirements to achieve support for ETS 
within the specific context of IP telephony (note that this document 
views IP telephony within the context of an end-to-end application 
layer service). Solutions to requirements are not defined. The 
document does not specify protocol enhancements or specifications. 


Note that [4], Requirements for Resource Priority Mechanisms for the 
Session Initiation Protocol (SIP), is an RFC that shares some overlap 
with this document. However, [4] only applies to SIP and is not 
meant to be applied to a more general perspective of IP telephony as 
it relates to ETS. 


2.1. Out of Scope 


An item that is not in scope of this document is mandating acceptance 
and support of the requirements presented in this document. The IETF 
does not mandate requirements or capabilities to independent networks 
that comprise the Internet. As an example, Internet Service 
Providers (ISP) may choose not to operate any telephony-related 
gateways or services. The IETF cannot and does not mandate that an 
ISP deploy either telephony-related gateways or telephony-related 
services. There is an expectation that business contracts, for 
example Service Level Agreements (SLA), will be used to satisfy those 
following requirements that apply to service providers. Absence of 
an SLA implies best effort service is provided. 


It is assumed that some ISPs will choose to offer ETS services and 


that other carriers will choose not to offer ETS services. These 
requirements do not apply to ISPs that have chosen not to offer ETS 
services. 
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3- 


IP Telephony Requirements 


The requirements in this section relate only to Telephony Signaling 
as used in Internet-based telephony services. They are an extension 
to the general requirements specified in [3]. The following 
requirements explicitly do not relate to IP-layer mechanisms, such as 
Differentiated Services or Integrated Services. 


1) 


Telephony signaling applications used with Internet-based 
telephony MUST be able to carry labels. 


The ability to carry labels MUST be extensible to support various 
types and numbers of labels. A single binary value will not be 
sufficient given the various labeling standards in existence 
today. 


Telephony signaling labels SHOULD have a mapping with the various 
emergency related labels/markings used in other telephony based 
networks, such as the Public Switched Telephone Network (PSTN). 
This ensures that a telephone call placed over a hybrid 
infrastructure (traditional PSTN over some portion(s) of the path, 
Internet telephony over some other portion(s) of the path) can 
carry the labels end-to-end with appropriate translation at 
PSTN/Internet boundaries. Absence of a mapping means that the 
signaling reverts to a default service (presumably one attributed 
to the general public). 


Application layer IP telephony capabilities MUST NOT preclude the 
ability to do application layer accounting. 


Accounting is a useful feature in support of billing and tracking 
down abuse of service. If specific solutions or protocols in 
support of ETS require accounting, then this will be articulated 
in future document (s). 


Application layer mechanisms in gateways and stateful proxies that 
are specifically in place to recognize ETS type labels MUST be 
able to support "best available" service (this will probably be 
realized as better than best effort). These labels MAY exist in 
the application layer headers of data (i.e., bearer) traffic or 
signaling traffic used for call completion. 


The support for best available service SHOULD focus on probability 
of forwarding packets. Probability MAY reach 100% depending on 
the local policy associated with the label. Local policy MUST 
also be used to determine if better than best effort is to be 
applied to a specific label (or related set of labels). 
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Additional comments on this topic are presented below in item 2 of 
section 4. 


The above paragraphs MUST be taken in their entirety. The ability 
to support best available service does not mean that the 
application layer mechanism is expected to be activated. Further, 
we do not define the means by which best available service is 
realized. Application layer mechanisms that do not recognize ETS 
type labels are not subject to this requirement. 


4. Issues 


This section presents issues that arise in considering solutions for 
the telephony requirements that have been defined for ETS. This 
section does not specify solutions, nor is it to be confused with 
requirements. Subsequent documents that articulate a more specific 
set of requirements for a particular service may make a statement 
about the following issues. 


1) Alternate paths 


Experience with The Government Emergency Telecommunications 
Service (GETS) over the PSTN has shown the utility of alternate 
paths to a destination to help facilitate emergency-related 
communications. From the perspective of the Internet, this 
utility may be difficult to achieve and have a more limited 
benefit. Unlike the PSTN, which creates a fixed path during call 
setup phase, the Internet uses dynamic routing for IP packets. 
This dynamic routing capability automatically causes IP packets to 
travel the best current path. The Internet network infrastructure 
does not have the concept of a "call" or the concept of "call 
setup", though IP telephony applications might have application 
layer awareness of calls or the call setup concept. 


2) Application of Best Available Service 


In item 5 of section 3 above, we discuss the requirement of 
supporting best available service. We note that in this document, 
the scope of that support is constrained to the application layer 
and flows that traverse that layer. This may involve direct 
support for the flow containing the ETS type label, or may involve 
indirect support (e.g., ETS labels in signaling messages that 
cause an effect on corresponding data or bearer flows). 
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5; 


6. 


6. 


It is critical to understand that how the support for best 
available service can be realized is outside the scope of this 


document. In addition, the perceived effectiveness of a given 
approach or implementation is also outside the scope of this 
document. 

Security 


Only authorized users or operators SHOULD be able to create non- 
ordinary Labels (i.e., labels that may alter the default best effort 


service). Labels SHOULD be associated with mechanisms to provide 
strong end-to-end integrity during their transmission through the 
telephony systems. Finally, in cases where labels are expected to be 


acted upon by operators, these operators SHOULD have the capability 
of authenticating the label on a received message or transmission in 
order to prevent theft of service and reduce risk of denial of 
service (e.g., by unauthorized users consuming any limited 
resources). 


Security is also discussed in the general requirements of [3], which 
applies to section 3 above. 
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8. Full Copyright Statement 
Copyright (C) The Internet Society (2004). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assignees. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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